Modern telecommunication systems may incorporate Policy and Charging Control (PCC) architectures. A PCC architecture is described in 3GPP TS 23.203 in respect of packet flows in an IP-CAN session established by a user equipment UE through a 3G telecommunications system. The particular architecture comprises: a Policy and Charging Rules Function (PCRF) and a Policy and Charging Enforcement Function (PCEF). The PCRF behaves as a Policy Decision Point (PDP) or Policy Server (PS), and the PCEF behaves as a Policy Enforcing Point (PEP). Whilst the PCRF can be implemented as a standalone node, it is preferably co-located within an Access Gateway (AG) such as a GPRS Gateway Support Node (GGSN) in a General Packet Radio Service (GPRS) core network. Related architectures are provided for 3GPP2 networks and TISPAN Next Generation Networks.
When a User Equipment (UE) initiates a data session, an IP address is assigned to it by an appropriate AG. The AG provides this IP address, together with, for example, an NAI, IMSI, or MSISDN, to the PS which in turn downloads into the AG a set of policy rules to be applied to the data session. When the UE communicates with a (final) Application Function (AF), the AF provides session details to the PS. When the UE subsequently requests resources for the service provided by the AF, the PS downloads into the AG a further set of policy rules based on the session details provided by the AF. In a 3GPP network, the AF may be a Proxy Call Session Control Function, P-CSCF, or another kind of application server to which the UE establishes an application communication via bearer(s) set up via IP-CAN session(s) through the AG.
Typically, a policy rule comprises a 5-Tuple vector describing a session (namely; orig IP-addr/port, dest IP-addr/port, protocol-TCP/UDP). The PCEF inspects packets to detect the relevant tuples and apply the rules. However, this technique allows only a limited (coarse) analysis of packets, as it does not allow packet inspection beyond these five IP headers, e.g. it does not allow inspection of payload data.
Inspecting packets at a deeper level, so-called Deep Packet Inspection (DPI), is possible, but is obviously more time and resource consuming, and can be unnecessary for some services. For example, an operator might be interested on applying PCC rules to “peer-to-peer” services, but not to other Internet-based services. DPI may also be employed for charging purposes. Typically, the DPI functions are passive elements. This means that they just “sniff” the IP packets but they do not manipulate them. Hence, if the outgoing IP packets in the uplink direction (UL) include the user IP address assigned by the gateway, the incoming IP packets in the downlink (DL) will be routed directly to the AG, thereby skipping the control function of the DPI node.
A solution is to implement a DPI node cooperating with a Network Address Translator (NAT). Such an architecture (3GPP TS 23.203) is illustrated in FIG. 1. The DPI implements the “Gx” interface so as to communicate with the PS when the session is initiated, and to receive policy rules from it. The AG in turn receive rules from the PS as to whether a packet is to be sent to the NAT or directly towards the appropriate AF (e.g. using standard routing tables). This allows, for example, packets relating to one service to be routed to the NAT and packets relating to another service to be sent directly to the appropriate AF (AF1 in the example of FIG. 1). The function of the NAT is to modify IP packets, sent by a UE, by changing the source IP address into a new (“NATed”) IP address which maps to that source address. The NATed address is selected from a given IP addresses range “owned” by the NAT. The NAT forwards the modified packets to the DPI node for inspection. The DPI in turn forwards the packets to the allocated AF (AF2 in the example of FIG. 1). By configuring edge IP router(s) for the incoming traffic in the downlink direction to route the allocated IP address range towards the DPI node, this approach ensures that packets sent by the destination node to the source UE are routed first to the DPI. Thus, DPI of both outgoing and incoming packets is ensured, whilst at the same time avoiding the need to perform DPI on packets for which this is unnecessary. The resulting traffic flows, NATed and non-NATed, are illustrated in FIG. 2.
The decision to route a given subset of the traffic towards a DPI element can be taken by evaluating a set of policies in the PS. The decision could be based, for instance, on the protocol, TCP/UDP port, source/destination IP address, RAT type, subscriber information, QoS info and serving network.
FIG. 3 illustrates a first issue associated with the NAT approach to enabling DPI (of both outgoing and incoming packets), namely that the DPI node cannot provide the PS with the UE IP address assigned by the AG as it only knows the NATed address. Currently, the UE IP address is used in the PS to correlate the service control session (e.g. Gx session) and the service session of the AF according to the 3GPP PCC architecture (TS 23.203).
A second problem arises due to the PS using the UE IP address to identify the IP-CAN session characteristics to in turn decide what PCC rules shall be installed. This prevents the PS from using data from the service control session with the AG in the PCC rule decision towards the DPI node and vice versa (for instance, to control the IP-CAN session Maximum QoS). Moreover, this prevents the PS from being able to push PCC Rules to one PEP in response to some trigger received from another PEP (for instance, to take action on the bearer QoS in the AG due to usage reporting by the DPI node).
Referring to FIG. 4, this shows that the DPI node is not involved during the General Bearer set-up (e.g. PDP context Creation, steps 1 to 7). For the DPI node, the trigger for the service control session creation towards the PS is the reception of the RADIUS Accounting start (steps 9 and 10). Although other data such as the subscriber IMSI is sent by the AG both to the PS and through the RADIUS interface (and hence is available to the DPI node), this information does not necessarily uniquely identify the IP-CAN session, due to the possibility of a user setting up several IP-CAN sessions (using different IP addresses). The absence of the UE IP address in the DPI node restricts the policy evaluation processes that may be employed by the network operator. At least the following 4 deficiencies had been identified:                1. The PS cannot properly control the characteristics set for an IP-CAN session, for example the maximum QoS per IP-CAN session, as each service control session behaves as a different IP-CAN session in the PS.        2. As a result of this policy evaluation process, the PS cannot decide to take actions to be enforced in the AG as well as in the DPI node.        3. The policy evaluation process initiated by the DPI node cannot be enhanced by evaluating session data sent to the PS by the AG in the initial policy evaluation process.        4. The policy evaluation process initiated by the DPI node cannot take into account the service information that an AF may provide to the PS, e.g. via the Rx interface, so as to enforce the appropriate decisions.        
The sequence diagram of FIG. 5 illustrates a second issue with the NATed approach to DPI. In particular, FIG. 5 shows a session correlation problem that arises when the AF is involved for dynamic service sessions (FIG. 5 is a simplified diagram, showing only those steps relevant to the problem). It is assumed that the UE has established a bearer so that AF signalling can be negotiated.
According to the Figure, UE-A negotiates a dynamic service session with UE-B, including Session Description Protocol (SDP) offer using its own IP address (IP-A). The other end sends an SDP answer with its own IP address (IP-B). The PS in the originating network generates PCC Rules with Service Data Flow for uplink (UL) and downlink (DL) directions that are installed in Access GW-A. For the UL direction, Service Data Filter contain: Source IP address is set to IP-A and destination IP address is set to IP-B. For the DL direction, Service Data Filter contains: Source IP address is set to IP-B and destination IP address is set to IP-A.
The PS in the originating network discovers that that the IP session contains a NATed IP address, so that PCC Rules should also be installed in the DPI. The new PCC Rule is generated with Service Data Flow for UL and DL directions that are installed in DPI. For the UL direction, Service Data Filters contains: Source IP address is set to IP-X and destination IP address is set to IP-B. For the DL direction, Service Data Filter contains: Source IP address is set to IP-B and destination IP address is set to IP-X.
The PS in the destination network generates PCC Rules with Service Data Flow for UL and DL directions that are installed in Access GW-B. For the UL direction, Service Data Filter contains: Source IP address is set to IP-B and destination IP address is set to IP-A. For the DL direction, Service Data Filter contains: Source IP address is set to IP-A and destination IP address is set to IP-B.
FIG. 6 illustrates what happens when UE-A decides to send packets to UE-B after session negotiation is terminated, over the bearer that corresponds to UL TFT=IP-B and port B. Access GW-A finds that packets match Service Data Flow for PCC Rule A, enforces the PCC Rule and forwards the packet. The packet transverses the NAT (that replaces IP-A by IP-X) and forwards the media packet. The packet is sent to the DPI that takes the decision to forward the media packet to the destination network. Access GW-B finds that the received packets do not match any Service Data Flow in PCC Rule B, so it drops the packets.